\documentclass[11pt]{article}

%\usepackage{ucs}
\usepackage[utf8]{inputenc}
\usepackage[czech]{babel}
\usepackage{graphicx}
\usepackage{multirow}
\usepackage{verbatim}

\def\CLICKABLEPDF{}
\ifx\CLICKABLEPDF\undefined
\newcommand{\urlref}[1]{\texttt{#1}}
\else
\usepackage[pdftex]{hyperref}
\hypersetup {
  unicode=true,
  colorlinks=true,
  pdftitle={Par Port Tester},
  pdfauthor={Lukáš Záruba, Jan Kuželka},
  pdfsubject={XD36PMT},
  linkcolor=black,
  citecolor=black,
  filecolor=black,
  urlcolor=black
}
\newcommand{\urlref}[1]{\texttt{\href{#1}{#1}}}
%\newcommand{\urlref}[1]{\url{#1}}
\fi

\author{Lukáš Záruba, Jan Kuželka}
\title{Par Port Tester}

\begin{document}
\maketitle \newpage

\newenvironment{code}
{\scriptsize\verbatim}{\endverbatim}

\tableofcontents \listoffigures 

\newpage
\section{Specifikace úlohy}
\subsection{Cíle a použití aplikace}
Cílem této aplikace je umožnit uživatelům jednoduché a efektivní testování
zabezpečovacích zařízení. Cílovou skupinou jsou společnosti, které provozují
akreditaci prvků zabezpečovacích zařízení a centrál EZS. Především pak testování
dostatečného splnění norem ČSN EN 50 136-1-1 a ČSN EN 50136-1-2, přesněji
klasifikaci podle přenosových časů do tříd D0 - D4 a klasifikaci intervalu
předání zprávy do tříd T1 - T6.

Tyto testy jsou prováděny při základních provozních podmínkách a ná\-sled\-ně po
aplikaci vlivů prostředí podle ČSN EN 50130-5. Mezi tyto patří například
sinusové vibrace, solná mlha, oxid siřičitý a další.

\subsection{Funkční požadavky}
Aplikace musí pracovat s paralelním portem\footnote{Vstupně-výstupní zařízení
podle normy IEEE 1284 pracující v režimu ECP - Extended Capabilities Mode}.
Tento požadavek vychází z předchozí implementace podobného systému, který však
již není v současné době použitelný a to především proto, že stále pracuje pod
operačním sys\-tém\-em MS-DOS\footnote{Microsoft Disk Operating System} a
předpokládá přímý přístup k portům. Zároveň také nesplňuje všechny požadavky na
testování. Připojena bude jedna vstupní a jedna výstupní linka.

Výstupní linka bude sloužit k vyslání spouštěcí události\footnote{Signál, který
odstartuje proces v externím zařízení. Tento proces může a nemusí vyústit ve
vyslání signálu zpět na vstup LPT}. V některých případech bude aplikace očekávat
návrat informace zpět na vstupní linku. Tento proces se může dít opakovaně a
mezi důležité parametry tohoto procesu patří délka stavu logická 0, stavu
logická 1 a z toho vyplývající délka periody. Dále počet opakování, adresa
portu, vstupní a výstupní offset\footnote{Přístup k paralelnímu portu je
realizován pomocí tří registrů. Ty se nazývají Base (+0), Status (+1) a Control
(+2). Pomocí různých registrů lze přistupovat k různým pinům portu. Offsetem je
míněn rozdíl mezi základní adresou (Base) a adresou na kterou se skutečně
přistupuje.} a vstupní a výstupní maska.

\bigskip Aplikace musí umožňovat uživateli provádět následující tři operace.
\begin{itemize}
  \item Odeslílání periodického signálu daných parametrů na výstupní linku. Tato
  operace slouží k testování životnosti mechanických externích za\-řízení, jako
  jsou například relé, jazýčkové kontakty magnetických spí\-načů, signální
  zařízení a další.
  \item Odesílání periodického signálu daných parametrů a registrace signálů na
  vstupní lince. Tyto signály mají reprezentovat odpověď externího zařízení.
  Důležitým atributem výsledku je doba do první odpovědi. Při tomto testu se
  obvykle používá pouze jedna perioda, nicméně není to pravidlem. Tato operace
  slouží především k testování reakční doby centrálních ústředen EZS.
  \item Odesálání perodického signálu s pevnou dobou trvání stavu logická 0 1
  sekundu a logická 1 také 1 sekundu. Nastavuje se především počet opakování
  periody. Zároveň je zjišťován celkový počet reakcí na vstupní lince.
\end{itemize}

\subsection{Požadavky na uživatelské rozhraní}
Zdavatel neprojevil žádné zvláštní požadavky na vzhled a
funkcionalitu uživatelského rozhraní. 

Uživateli budou především muži ve věku 40 - 70 let. Tito uživatelé budou mít
vysokou znalost problémové domény. Jejich obecná schopnost ovládat počítač je
nízká až střední a vychází především z podrobných znalostí dnes již
nepoužívaných technologií a SW.

Toto zadání vzniklo po úvodní studii v prostředí zadavatele, tedy firmy
TESTALARM Praha s r.o..

\section{Analýza zadání}
Po základní přípravě zadání se zadavatelem byla provedena analýza tohoto zadání
a připaveny přehledné body, které toto zadání rozšíří a zpřehlední. Tyto body
byly následně po drobných úpravách zadavatelem schváleny. Rozšiřující analýzu
jsem provedl na základě pozorování zaměstnanců zadavatele při práci s původní
aplikací i při provádění dalších činností, které s touto problematikou přímo
souvisí.

\begin{itemize}
  \item Aplikace musí pracovat v prostředí Windows XP SP2 a vyšší. Verze pro
  32 bitů.
  \item Aplikace musí být jednoduše ovladatelná i pro uživatele, kteří mají
  nižší a střední znalost práce s PC.
  \item Aplikace musí disponovat těžkým klientem vzhledem k přístupu k nativním
  prostředkům systému.
  \item Časová přesnost zápisu a čtení dat musí být do 10ms za předpokladu
  použití procesoru třídy Mobile Pentium 4 a vyšší.
  \item Není třeba, aby aplikace podporovala rozšiřující porty LPT provozované
  přes USB.
  \item U signálů odpovědi je rozhodující celkový počet vzestupných hran za dobu
  celého měření a doba do první odpovědi. Není tedy třeba testovat vstupní
  signály v závisloti na signálu výstupním.
  \item Před každým měřením bude nastavena HW adresa portu LPT, vstupní a
  výstupní offset a vstupní a výstupní maska.
  \item Vstupní a výstupní maska budou mít právě jeden bit ve stavu logická 1,
  zbytek logická 0.
  \item Přístup na port z uživatelského režimu bude zajištěn externí aplikací,
  která zavede ovladač do režimu jádra.
\end{itemize}

Po pozorování jsme došli se zadavatelem k závěru, že kromě původních tří
produkčních operací, by aplikace měla obsahovat také rozhraní pro testování
správného nastavení vstupně-výstupního zařízení. Mělo by být možné odeslat data
na port a přečíst stav na daném portu.

\section{Analýza uživatelského rozhraní}
Po dokončení analýzy funkcionality jsme přistoupili k analýze uživatelského
rozhraní. Vzhledem k tomu, že předchozí aplikace jako své rozhraní využívala
CLI\footnote{Command-line interface}, nebylo možné vycházet z této předlohy.

Proto byla vytvořena persona, která nám umožnila lépe pochopit přístup koncového
uživatele k aplikaci. Vzhledem k tomu, že podle zadavatele je cílová skupina
uživatel homogení, stačilo pro dostatečnou reprezentaci vy\-tvořit personu
jednu. 

Touto personou je muž ve věku 58 let, který většinu své pracovní doby tráví
manipulací s elektronickými zařízeními. Tento muž, nazývejme ho Zbyněk, používá
počítač k práci asi 1/5 své pracovní doby. V soukromí počítač používá k přístupu
na internet.

S ohledem na tuto personu jsme zvolili mírně zdlouhavý, nicméně jedno\-duchý a
přímočarý postup při provádění úkonů v uživatelském rozhraní. Kompletně jsme se
vyhnuli trvalému nastavování aplikace a všechna nastavení je třeba upravit při
každém měření. Tento přístup klade požadavek na správný odhad nejčastějších
nastavení pro měření, aby byla potřeba nastavení měnit co možná nejmenší.

Zadavateli byl navržen základní princip
rozhraní takový, že aplikace začíná v tzv. rozcestníku, odkud je možné spouštět
průvodce jednotlivými úlohami. Tento průvodce umožní uživateli nastavit všechny
para\-metry da\-ného testu a následně test spustit. Průběh testu bude uživateli
znázorněn pomocí ukazatele a textového popisu. Jakmile test skončí, bude
zobrazeno okno se sumarizací výsledku. Po deaktivaci tohoto okna se uživatel
vrátí do původního rozcestníku.

Tento návrh byl zadavetelem schválen a zároveň vznikly první skicy tohoto
prostředí. Tyto skicy pak byly zpracovány pomocí aplikace Balsamiq
Mockups\footnote{\urlref{http://balsamiq.com/products/mockups}}
do interaktivního pdf, které znázorňovalo průchod uživatele skrz rozhraní, viz. příloha.

Tato metoda je
v praxi velice účinná, protože umožňuje diskutovat se zadavetelem nad podrobným návrhem
uživatelského rozhraní, aniž by toto rozhraní muselo být vytvořeno v cílové
platformě. Vzhledem k tomu, že v tomto okamžiku obvykle ještě není přesně jasné,
jaká platforma bude na rozhraní použita, přináší tento produkt firmy Balsamiq
nespornou úsporu času a prostředků. Další výhodou je vysoká flexibilita při
vytváření a úpra\-vách. 

Jedním ze základních požadavků na tyto low-fidelity
prototypy je, aby se zadavatel příliš neupnul na detaily grafického provedení,
ale spíše na postupy a průchody jednotlivými operacemi. Díky jedinečnému vzhledu
výstupních prototypů z produktu Balsamiq Mockups je tento požadavek jednoznačně
splněn. 
\begin{figure}[h!]
	\caption{Ukázka výstupu aplikace Balsamiq Mockups. Zde jedna stránka
	průvodce}
	\begin{center}
		\includegraphics[scale=0.5]{../img/dynRespParams.png}
	\end{center}
\end{figure}

Po prezentaci připravovaného rozhraní byly zapracovány úpravy a po\-žadav\-ky
zadavatele a bylo možné přistoupit k volbě technologií, které budou použity a
následně k samotné výrobě aplikace.

Seznam požadavků, který doplňuje vytvořené mockups:
\begin{itemize}
  \item Aplikace by vzhledem k ne příliš vysokým znalostem uživatelů měla být
  realizována za pomoci prvků, které tématicky zapadají do prostře\-	dí Windows
  XP.
  \item Aplikace musí být lokalizována do češtiny, nicméně její použití se
  dlouhodobě předpokládá i v jiných zemích, například Polsku, takže je třeba
  zavést překladový systém.
  \item Všechny postupy a operace uživatele musí být dostatečně kontrolovány a
  například neplatné vstupní hodnoty musí znemožnit další pokračov\-ání až do
  opravení dat uživatelem.
  \item Výsledek stačí zobrazit, není třeba ho exportovat do souboru nebo
  schránky. Z pohledu normy stačí vyjádření technika doplněné patřičn\-ými
  technickými daty.
  \item V případě technického problému s aplikací musí být uživatel upozorněn
  přeloženým smysluplným textem, který umožní následný jednoduchý přenos
  informace o chybě k výrobci a opravení této chyby. S tím se pojí i potřeba
  dostatečného logování.
\end{itemize}

\newpage

\section{Použité technologie}

Volba programovacího jazyka, frameworku a IDE vychází z~předešlé zkušenosti
z~bakalářské práce Univerzální analyzátor signálů \cite{bachelor_thesis}, tedy
opět je použita Java s~Eclipse IDE for~RCP/Plug-in Developers. Nově je použito
pouze Balsamiq Mockups pro modelování konečného UI.

\subsection{Java}
Java je objektově orientovaný programovací jazyk vyvinutý společností Sun
Microsystems. Syntaxi má podobnou jazyku C++, nicméně jde o interpretovaný
jazyk. Zdrojový kód je přeložen do tzv. \uv{bytecodu}\footnote {Bytecode -
mezijazyk vytvořený pro potřeby Java Virtual Machine, do kterého se překládají
zdrojové kódy v~různých jazycích}, který je následně spuštěn Java Virtual
Machine (JVM). Virtual Machine (VM) je pro každou platformu odlišný, to právě
umožňuje velmi snadou přenositelnost bytecodu. \cite{java}

Hlavní výhodou Javy je platformová nezávislost a to díky interpretaci bytecodu,
co by \uv{mezikódu}. Naopak nevýhodou tohoto jazyka je nemožnost přímého
přístupu k~low-level prostředkům, namísto toho je použita technologie
JNI. \cite{jni}

Co lze nazvat další výhodou, ale i nevýhodou, je správa paměti tzv. \uv{Garbage
collectorem} (GC). GC zajišťuje správnou dealokaci použitých prostředků. Díky GC
se Java vývojář vyhne typickým problémům C/C++ vývojářů jako je neoprávněný
přístup k~paměti (segmentation fault) či neuvolněná paměť (memory leak).
V~některých situacích ale může činnost GC znamenat problém. Java vývojář jako
takový nemá přístup k~řízení GC, pak např. v~okamžiku provádění bloku kódu,
který má být proveden v~nejkratším možném čase (time-critical code), je činnost
GC nežádoucí. Tento \uv{defekt} je alespoň částečně kompenzován stále
rychlejšími GC.

%\subsubsection{JNI}

\subsection{Eclipse}

\subsubsection{Eclipse Platform}
Eclipse Platform je rozšířitelná open source vývojová platforma, která vznikla
uvolněním kódu projektu (Eclipse 1.0) společností IBM pod EPL licencí a to
v~listopadu 2001 \cite{eclipse_platform}. Samotný projekt byl vyvinut
společností \mbox{Object} \mbox{Technology} \mbox{International} \mbox{(OTI)}
jako java-based nástupce celé rodiny IBM \mbox{VisualAge} IDE, která byla
založena na \mbox{SmallTalku}.

Eclipse Platform může být s jistotou nazván frameworkem\footnote{Framework -
softwarová struktura, která slouží jako podpora při programování, vývoji a
organizaci jiných softwarových projektů. Může obsahovat podpůrné programy,
knihovnu API, návrhové vzory nebo doporučené postupy při vývoji.} a to díky své
robustní implementaci, která na své nejvyšší úrovni umožňuje uživateli vytvářet
rychlé a spolehlivé aplikace.

Runtime systém Eclipse je založen na Equinoxu\footnote{Equinox - Eclipsový
projekt, který poskytuje certifikovanou implementaci OSGi R4 core framework
specifikace. V současné době je OSGi framework považován za nejvyspělejší
modulární systém pro Javu}, vše ostatní je tzv. \mbox{\uv{plugin}}.

V současné době se vyvíjí již 4\@. verze Eclipse SDK. Eclipse Platform od roku
2001 nabírá na popularitě a na její bázi vzniklo již mnoho známých
projektů jako např. tyto \cite{eclipse_based_projects}:

\begin{itemize}
  \item Borland JBuilder 2007 - IDE pro Javu i pro tvorbu rozsáhlých podnikových
  aplikací
  \item CodeWarrior - IDE pro C/C++ pod operačními systémy Macintosh, Microsoft
  Windows, Linux, Solaris a vestavěné systémy (např. Symbian OS)
  \item IBM Lotus Notes 8 - platforma pro vývoj
  groupware\footnote{Groupware - počítačové nástroje napomáhající ke spolupráci
  lidí (např. pracovníků) na nějakém společném díle} aplikací
  \item IBM Rational Software Architect - flexibilní, rozšiřitelná a snadno
  použitelná platforma pro dodávání kvalitních architektur
  \item IBM Workplace Client Technology - komplexní prostředí zahrnující web.
  prohlížeč, e-mailového klienta a specifické pluginy klienta
  \item NASA Maestro project - nástroj pro plánování a správu misí ve vesmíru
  s~možností vizualizace, simulace, atd.
  \item Oracle Real Time Decision - Decision Studio - nástroj pro vývoj
  adaptivních podnikových řešení
  \item Sybase PowerDesigner - CASE nástroj pro správu vývoje software
  (modelování systémů, generování zdroj. kódu, atd.)
\end{itemize}

a mnoho dalších\ldots{}

\paragraph{OSGi}
Součástí Eclipse Platform verze 3 a vyšší je modulární systém OSGi Framework
\cite{osgi}, který umožňuje instalaci a odebírání modulů za běhu (bez nutnosti
restartu). Definuje životní cyklus modulu a nabízí infrastrukturu pro spolupráci
modulů skrze služby.

\subparagraph{OSGi bundle}
Jednotkou modularity v~OSGi je takzvaný \uv{bundle}. Je to běžný JAR archiv
s~několika speciálními hlavičkami v~manifestu. Každý modul má za běhu speciálně
vytvořený zavaděč tříd (classloader), který vidí pouze Java balíčky a zdroje
(obrázky, konfigurační soubory a další) definované v~modulu samotném, části
standardní knihovny odpovídající specifikovanému prostředí (např. JRE) a balíčky
z~ostatních modulů, které explicitně importuje.

Níže je MANIFEST.MF soubor jednoduchého modulu.

\begin{code}
Bundle-Name: Hello World
Bundle-SymbolicName: org.wikipedia.helloworld
Bundle-Description: A Hello World bundle
Bundle-ManifestVersion: 2
Bundle-Version: 1.0.0
Bundle-Activator: org.wikipedia.Activator
Export-Package: org.wikipedia.helloworld;version="1.0.0"
Import-Package: org.osgi.framework;version="1.3.0"
\end{code}

OSGi bundle (a také Eclipse Plugin) má tento životní cyklus:

\begin{itemize}
  \item INSTALLED - bundle je nainstalován
  \item RESOLVED - exportované balíčky bundle jsou dostupné ostatním modulům
  \item STARTING - bundle může být nastartován - je zavolána metoda \emph{start}
  jeho aktivátoru, pakliže je definován
  \item ACTIVE - bundle byl úspěšně nastartován, nyní je aktivní dokud není
  zavolána metoda \emph{stop} aktivátoru
  \item STOPPING - bundle může být zastaven - je zavolána metoda \emph{stop}
  jeho aktivátoru
  \item UNINSTALLED - bundle je odinstalován, toto je konečný stav 
\end{itemize}

Ve fázi \uv{STARTING} a \uv{STOPPING} může být registrován a následně volán
tzv. \uv{hook} pro provedení některých operací jako načtení nebo uvolnění
zdrojů, vytvoření nebo uzavření připojení k databázi atd. Nicméně tato fáze
není vhodná pro provádění časově náročných operací, může dojít k~timeoutům či různým
problémům souvisejících s~příliš dlouhým prováděním kódu.

\subparagraph{Equinox}
Equinox je Eclipsový projekt \cite{equinox}, který poskytuje certifikovanou
implementaci OSGi R4 core framework specifikace. Objevil se poprvé v~Eclipse
verzi 3.0, kde nahradil tehdejší \emph{Eclipse plug-in runtime} (rok 2004).

Equinox jako takový je runtime modul, který umožňuje vývojářům v~Eclipse
implementovat aplikaci jako množinu \uv{bundlů} užívající dané služby a
infrastrukturu.

\paragraph{Eclipse Plugin}
Eclipse Plugin je základní element Eclipsové aplikace - obvykle rozšiřuje její
schopnosti. Každá Eclipse aplikace se skládá z~množiny pluginů, kde každý plugin
může být propojen s~jinými pluginy. Díky pluginům může uživatel snadno
spravovat, rozšiřovat a používat jednotlivé funkcionality, které jinak bývají
zakódovány přímo do samotné aplikace. \cite{eclipse_plugin}

Jako příklad Eclipse pluginu lze uvést
Eclox\footnote{\urlref{http://home.gna.org/eclox}}.
Tento velmi jednoduchý a přitom velmi užitečný plugin byl vytvořen pro snadné generování
Doxygenové\footnote{\urlref{http://www.doxygen.org}}
dokumentace zdrojových kódu do HTML či \LaTeX{}u. Sám nedělá nic jiného, než že spouští generátor dokumentace
s~konfiguračním souborem (doxyfile), který lze v~Ecloxu vyplnit přes GUI průvodce.

\subparagraph{Načtení pluginu}
Při startu aplikace tzv. \uv{loader} zkontroluje, které pluginy se mají
načíst\footnote{Pluginy lze vybrat i ručně nebo lze přímo specifikovat, které
pluginy mají být načteny dynamickým loaderem}. Následně se zpracuje seznam
závislostí pluginů (za předpokladu, že nejsou cyklické závislosti) a začnou se
načítat bundly.

Uvnitř pluginu je tzv. \uv{Activator}. Což je třída, která musí být potomkem
třídy
\begin{code}
org.eclipse.core.runtime.Plugin
\end{code}
aby její metody
\begin{code}
void start(org.osgi.framework.BundleContext)
void stop(org.osgi.framework.BundleContext)
\end{code}
mohly být volány ve STARTING a STOPPING fázi pluginu.

\subparagraph{Obsah pluginu}
Eclipse Plugin je vlastně OSGi bundle s manifestem, Java třídami a případě
dalšímu doplňky jako konfigurační soubory, knihovny či soubory pro vícejazyčnou
verzi pluginu. Prakticky vše, co vývojář může potřebovat k~vytvoření pluginu.

Kromě manifestu \mbox{MANIFEST.MF} obsahuje plugin také soubor
\mbox{PLUGIN.XML}. Tento soubor specifikuje tzv. \uv{Extensions} a \uv{Extension
Points} pluginu.

Plugin také může využívat prostředky, které se do výsledné verze nepřidávají,
pouze se na ně vytvoří odkaz (např. reference na JAR soubor, který lze stáhnout
z~Internetu). To může být žádoucí v~situaci, kdy knihovna, kterou využíváme, je
příliš velká a nechceme ji zahrnout do výsledné verze. Správu takového přístupu
k~prostředkům řeší soubor \mbox{\uv{build.properties}}.

\paragraph{Eclipse Fragment}
Eclipse Fragments (fragmenty) jsou podobné pluginům. Mají podobnou
strukturu (místo \mbox{PLUGIN.XML} obsahují \mbox{FRAGMENT.XML}), ale liší se
hlavně v~použití a účelu. \cite{eclipse_fragment}

Fragment nemůže být použit jako samostatná komponenta, musí mít svůj
hostující plugin.

Účel fragmentu je rozšířit tzv. \uv{classpath} hostujícího pluginu. To se může
hodit např. když má být plugin vícejazyčný, kde namísto přepisování jednotlivých
řetězců se pro každý jazyk vytvoří fragment, který podle nastavené classpath
použije ty správné řetězce.

\paragraph{Eclipse Feature}
Eclipse Feature (featura) ve světě Eclipse znamená popis či seskupení
funkcionalit jednoho či více pluginů, které dohromady utváří konkrétní produkt.

Featura neobsahuje kód, pouze popisuje co vlastně jednotlivé pluginy provádění,
jak je aktualizovat, popř. obsahuje i další featury. Featury jsou opět
zabaleny do manifestu - XML souboru \mbox{FEATURE.XML}. \cite{eclipse_feature}

Důvod, proč vytvářet Eclipse Features je celkem jasný - jednoduchý a pohodlný
přehled pluginů, jednoduchá instalace přes Eclipse
MarketPlace\footnote{\urlref{http://marketplace.eclipse.org}}
a samozřejmě díky možnosti aktualizace i snadný update jak vlastních, tak participujících pluginů
(např. \uv{samoaktualizující se} pluginy Eclipse IDE).

\paragraph{Eclipse Extensions}
Eclipse Extensions (extensions) lze jednoduše označit za rozšíření Eclipse
pluginů - přidání nějaké nové funkcionality existujícímu pluginu. K~tomu se
využívají tzv. \uv{Extension points}, což jsou přístupové body
(\verb+~+rozhraní), definované vývojářem daného pluginu, pro přidání tzv.
\uv{Contribution} (příspěvku) do pluginu. Např. přidání uživatelského commandu
do command menu pluginu.

Díky extensions dokáže vývojář nový kód lépe spravovat, dokáže přidávat novou
funkcionalitu aniž by v~původním pluginu cokoli měnil (plugin o~charakteru
příspěvku mimo Extension points nic neví). Extension points jsou definované
v~manifestu \mbox{PLUGIN.XML}, případně v~\mbox{FRAGMENT.XML}. Při vývoji se
pro svou složitost obvykle využívá Eclipse průvodce/editoru.

\subsubsection{Eclipse RCP}
Eclipse Rich Client Platform (RCP) je nejmenší možná množina pluginů, která je
zapotřebí k~vytvoření \uv{bohaté} klientské aplikace \cite{eclipse_rcp}. RCP je
složena z těchto komponent:

\begin{itemize}
  \item OSGi - bundling framework (správa modulů)
  \item Core platform - zajišťuje správné spuštění Eclipse a běh pluginů
  \item SWT - sada nástrojů pro práci s GUI v Javě
  \item JFace - MVC architektura nad SWT
  \item Eclipse IDE - perspektivy (různé formy editorů), správa oken
\end{itemize}

\paragraph{Pracovní prostředí, perspektivy, pohledy, editory}
Díky konceptu příspěvků (rozšíření Eclipse pluginů) je možné používat
v~pracovním prostředí (Workbench) Eclipse RCP perspektivy (Perspectives),
editory (Editors) a pohledy (Views).

Perspektiva je množina pohledů a menších doplňků (např. command menu)
v~konkrétním rozvržení (layoutu). Pohled je vizuální reprezentace dat nebo
akce, např. v~text. procesoru, webovém prohlížeči apod.

Editor je velmi podobný pohledu. Od pohledu se liší hlavně tím, že může mít více
instancí. Pohled smí mít pouze jednu. Pohled je závislý na dané perspektivě,
editor je stejný bez ohledu na perspektivu. A samozřejmě, editor upravuje data,
pohled data pouze interpretuje.

\paragraph{SWT}
Standard Widget Toolkit (SWT) je OS nezávislá knihovna grafických uživatelských
prvků pro platformu Java. Původně byla tato knihovna vyvinuta firmou IBM. Nyní
je ve správě nadace Eclipse Foundation \cite{swt}.

Alternativou k~této knihovně je SWING a starší AWT od společnosti Sun
Microsystems. AWT byl představen v~JDK 1.0. Byl to jednoduchý Java wrapper
(obal) okolo systémem poskytovaných ovládacích prvků (widgetů) jako menu, okna a
tlačítka. Ačkoliv to byl wrapper okolo nativních komponent, přenesení AWT na
nový operační systém mohlo trvat neúměrně dlouho, mohly se objevit problémy
s~kompatibilitou atd.

Novější SWING používá Java 2D\footnote{API pro kreslení 2-rozměrné grafiky
v~programovacím jazyku Java \cite{java_2d}} pro vykreslení vlastních komponent
než použití nativních. To umožňilo aplikacím mít stejný vzhled a prostředí (look
and feel) bez ohledu na OS. Nevýhodou SWINGu byl jeho výkon a to právě proto, že
si všechny komponenty kreslil sám.

SWT je také wrapper okolo nativních komponent podobně jako AWT. Bylo navrženo tak aby
bylo výkonné, rychlejší, lehčí a s~lepší schopností využití systémových
prostředků než SWING. Místo přímého propojení s~nativními komponentami využívá
technologie JNI pro volání nativních knihoven. Tím se přiblížil k C++, jehož
aplikace taktéž volají nativní GUI knihovny. Pakliže ale tyto knihovny
neposkytují funkcionalitu žádanou SWT, funkc. je implementována podobně jako
ve~SWINGu.

\paragraph{JFace}
JFace je UI framework pro zjednodušení práce s~často opakujícími se UI úlohami.
Je platformově nezávislý a to jak jeho implementace, tak API. Usnadňuje také
práci s~SWT (používá MVC model) - poskytuje nadstandardní grafické prvky jako
různé druhy oken, dialogy, lišty, menu a také průvodce, různé typy pohledu atd.
\cite{jface}

\subsubsection{Eclipse IDE}
Eclipse IDE je multijazyčný software obsahující integrované vývojové prostředí
(IDE) a rozšiřitelný plug-in systém. Z~větší části je napsán v~Javě a díky
unikátní architektuře (systému pluginů) dnes může sloužit k~vývoji aplikací
téměř v~jakémkoli programovacím jazyce.

Eclipse IDE for RCP obsahuje několik velmi důležitých modulů (bundles). Mezi
nejdůležitější patří JDT a PDE.

Java Development Tools (JDT) poskytují mnoho různých editorů, pohledů, builderů
a hlavně průvodců, které automatizují často opakující se procesy. Obsahuje také
nástroje pro zobrazování varování a chyb, refactoring, code-merging apod.
\cite{jdt}

Plug-in Development Environment (PDE) stejně jako JDT pomáhá s~vývojem
v~Eclipse. Poskytuje nástroje pro vývoj pluginů, fragmentů, featur,
aktualizačních sítí a RCP produktů. \cite{pde}

%\subsection{Mockups}

%\subsubsection{Balsamiq Mockups}

\newpage
\section{Implementace}
Implementace probíhala v již zmíněném vývojovém prostředí Eclipse IDE. Díky tomu
bylo možné používot širokou škálu podpůrných nástrojů, jako jsou
code-completition, velmi pokročilé formy refactoringu, předlohy často
používaných prvků jazyku Java a další. 

Narozdíl od tradičního modelu výroby aplikací byla první vytvořena část
grafického rozhraní a to především kvůli tomu, že díky následnému sezení se
zadavetelem bylo možné konkrétně odladit seznam klíčových parametrů testů.

Druhým důvodem byl poměr rozsahu kódu front-endu, tedy GUI a back-endu, tedy
samotného přístupu k nativním prvkům systému a postup měření. Tento poměr byl
odhadnut na 2:1 a i v závěrečné fázi implementace byl potvrzen. Tento fakt
zmiňuji především proto, že se jedná o techniku často zbytečně zatracovanou.
Tento projekt je přesvědčivým důkazem, že v situaci, kdy aplikaci vyvýjí menší
tým a v pozici stakeholdera na straně zákazníka se vyskytuje osoba, která s
podobnými projekty nemá zkušenosti, umožní přednostní vývoj uživatelského
rozhraní podrobnou debatu nad postupy aplikace, které z poměrně jasných důvodů
nejsou předem zřejmé z již zmiňova\-ných mockups.

\subsection{Implementace prvků uživatelského rozhraní}
Postup vývoje vycházel z předlohy bakalářské práce Universal signal
analyzer \cite{bachelor_thesis}. Z této předlohy byly v zásadě bezvýhradně
převzaty základní součásti aplikační platformy. Ty byly pouze zjednodušeny a to
především tím, že celá aplikace nepoužívala klasické rozložení části Workbench,
nýbrž pouze jedno okno, které slouží jako jakýsi rozcestník celé aplikace. Z
tohoto rozcestníku pak vychází průvodci, kteří uživatele provedou procesem
přípravy nastavení celého procesu a následně spustí akci na pozadí, jejíž průběh
je uživateli sprostředkován pomocí vloženého ukazatele průběhu. Tento postup je
standartní ve všech aplikacích založených na platformě Eclipse RCP.

\subsubsection{Hlavní okno aplikace}
Jak jsem již zmínil, základem aplikace je okno, které slouží jako rozcestník.
Toto okno dědí abstraktní třídu ViewPart a přepisuje především hlavní metodu
createPartControl. Tato metoda potom slouží k vytvoření a aktivaci prvků
uživatelského rozhraní. Vytvoření několika tlačítek je poměrně přímočarou
záležitostí a není proto potřeba detailněji rozebírat. Součástí třídy je
statická vnitřní třída RunWizardListener. Cílem této třídy je poskytnout
jednoduchý přístup k několikrát použitému postupu spouštění průvodce. Tato
vnitřní třída implementuje rozhraní SelectionListener a proto může být její
instance přímo předána metodě addSelectionListener na tlačítku. Tím se vyhneme duplicitě kódu v
rozsahu několika desítek řádek.

\subsubsection{Implementace průvodců}
Každý průvdce dědí od abstraktní třídy Wizard. V naší aplikaci jsme potom
připravili dalšího abstraktního potomka této třídy, který se nazývá
AbstractRespWizard a cílem jeho existence je sjednotit chování, které je
společné pro dva ze tří průvdců. Tyto průvdci akceptují odpovědi od zařízení.
Celý proces přípravy, spuštění procesu na pozadí a zobrazení je sjednocen.
Abstraktní metoda prepareRunnable slouží k předání příslušné úlohy, která potom
bude spuštěna na pozadí. Takto bylo opakovaně využito překladových zdrojů a bylo
vytvořeno velice elagantní řešení, které umožňuje velice snadné přidání dalších
úloh v budoucnu. Dvě konkrétní implementace této abstraktní třídy jsou potom
A1SWizard, tato představuje měření s periodou dvou sekund a DynWizard která
reprezentuje volně nastavitelné (dynamické) měření s analýzou počtu odpovědí.

Druhou větví této části aplikace je DynNoRespWizard, který reprezentuje měření,
při kterém není v úvahu brána odpověď od měřícího zařízení. Tato třída přímo
dědí od třídy Wizard a je tedy paralelní větví k AbstractRespWizard. Důvodem k
tomuto architektonickému rozhodnutí bylo to, že tento průvodce v zásadě nesdílí
žádnou důležitou funkcionalitu s předešlou větví.

Obě tyto větve spouští v rámci metody performFinish, která se volá při ukončení
průvodce, vlákna s úlohou na pozadí. Tato
úloha musí potom implementovat rozhraní IRunnableWithProgress. Díky tomu může
reportovat zpět do UI vlákna postup procesu a může přijmout inforamci o tom, že
měření má být ukončeno.

Speciálním případem průvodce je testovací proces. Tento průvdce nikdy nejde
dokončit a jedná se v zásadě o špatné použítí průvodce. Ale navzdory tomu je
tato varianta pro implementaci výhodná, protože tento průvodce znovupoužívá některé
stránky nastavení, které budou zmíněny v následující sekci. Díky tomu, že pro
uživatele je rozdíl mezi použitím průvodce a souslednosti konvenčních oken téměř
nerozeznatelný a zároveň tato varianta vhodně zapadá do celkové koncepce
aplikace, považujeme ji za vhodnou.

\subsubsection{Společné stránky průvodců}
Vzhledem k tomu, že úlohy, které průvodci spouští mají společnou základnu
problematiky, je možné určité stránky průvodců znovupoužít.

Jedná se především o stránky, které slouží k nastavení parametrů vstupně
výsupních zařízení. Protože nejzákladnější varianta procesu je pouze výstupní,
je i základní třídou rozšiřující abstraktní třídu WizardPage třída OHWPage. Tato
třída implementuje nastavení parametrů výstupního hardware. 

Jejím potomkem je
třída IOHWPage, která chování předchozí stránky rozšiřuje o nastavení parametrů
vstupního hardware. Mezi tyto parametry na obou stranách patří adresa portu,
offset I/O bajtu a maska, která se aplikuje na vstup i na výstup. Obě tyto
stránky potom předávají výsledné nastavení. Aby bylo možné zavést objektové
principy i sem, tak stránka nastavující výstupní parametry vrací základní balík nastavení.
Tato třída nastavení je pak dále rozšířena třídou, která už vrací vstupní i
výstupní nastavení.

\subsection{Internacionalizace prvků uživatelského rozhraní}
Pro internacionalizaci, která je obvykle reprezentována zkratknou
i18n\footnote{první a poslední písmeno slova Internationalization. Číslo 18
potom značí počet písmen} a je často milně zaměňována s
lokalizací\footnote{Zkratka l10n jako localization a opět počet písmen}, jsme
použili základní nástroje platformy Eclipse RCP a Eclipse IDE. 

Součást těchto nástrojů, která je k dispozici v runtime prostředí se skládá z
třídy Messages, která rozšiřuje základní překladovou třídu NLS. Tato třída se
potom používá tak, že se přidávají veřejná statická pole typu String. Tato pole
jsou při načtení reflexivně naplněna z příslušného properties souboru pro daný
jazyk, který odpovídá jazyku prostředí Java, popřípadě základnímu jazyku, pokud
předchozí není k dispozici. Díky tomuto postupu je použití messages mnohem
jednodušší, než je obvyklé řešení, které vyžaduje volání metody, které se předá
klíč.

Velikou službu také udělá nástroj na internacionalizaci pluginů, který je
součástí PDE\footnote{Plugin Development Environment}. Tento nástroj umí po
analýze projít kód a najít potencionální řetězce pro internacionalizaci. Pokud
se uživatel rozhodne, že řetězec, například id nebo název extension pointu, není
vhodný pro internacionalizaci, aparát přidá komentář, který při příštím spuštění vyloučí
zbytečné redundantní dotazování na tento řetězec. Mezi další nástroje, které
mohou být také použity patří například analýza nepoužívaných překladů v
properties souborech nebo nástroj pro nalezení řetězců, které nejsou přeloženy
do všech dostupných jazyků. Soubor těchto nástrojů dohromady umožňuje použít
stabilní postup překladu, který zamezuje nepřesnostem a vynechaným překladům.
Díky tomu aplikace vždy působí profesionálně a neodrazuje svým vzhledem.

Jak již bylo zmíněno na začátku této práce, fragment může rozšiřovat classpath
pluginu, aniž by o tom měl plugin přímou informaci. Díky tomu jsou na překlady v
tomto případě použity právě fragmentu. Základním jazykem je angličtina. V tomto
jazyce byla aplikce vytvořena ještě před začátkem internacionalizace. Čeština
byla přidána jako fragment. Překladová data se nacházejí ve stejném uspořádání
jako v originálním pluginu, ale posunutá do složek /nl/cs ve fragmentu.

\subsection{Implementace samotného měření}
Samotné měření bylo implementováno ve zvláštním pluginu, aby mohlo být případně
znovupoužito při dalším rozšíření, případně při vývoji podobné aplikace.

Základním stavebním prvkem celého backendu je třída OutputRunnable. Tato
implementuje rozhraní IRunnableWithProgress a vzhledem k tomu, že je uvažována
jako bod rozšíření, je parametrizována jako ``T extends OutputTestResult''. Třída
OutputTestResult v tomto případě reprezentuje výstup z procesu odesílání vzorků
na výstupní zařízení. Mezi parametry odesílání patří počet provedených
opakování, doba která uběhla a další.

Funkcionalita této třídy spočívá v cyklickém nastavování výsupního vzoru 0 nebo
1 na výstupní zařízení. Mezi jednotlivými půlperiodami je realizováno čekání za
pomoci metody java.lang.Thread.sleep(long). Protože tato třída je určena k
dědění, jsou implementovány prázdné protected metody callStopHook, callStartHook a
callCycleHook, které slouží pro zapojení specifických operací do průběhu
životního cyklu této třídy, aniž by bylo třeba duplikovat její kód.

Jak již vyplývá z předchozího popisu, je potomkem této třídy
OutputRunnableWithResp. Tato třída dědí OutputRunnable a je parametrizována jako
``OutputTestResultWithResp''. OutputTestResultWithResp jak je zřejmé dědí
OutputTestResult a přidává další informace o vstupu dat do vstupního zařízení.
Hlavním cílem tohoto rozšíření je spustit aparát, který pravidelně testuje
vstupní zařízení a počítá jak celkový počet reakcí za celou dobu měření, tak
dobu do první reakce, která je pro zadavatele velice důležitým parametrem.

Celý tento proces je realizován třídou InputRunnable. Ta ve své hlavní části
provádí smyčku ukončenou signálem konce měření. V této smyčce potom testuje stav
vstupního zařízení a počítá množství raising edges stavů. Tato třída
implementuje rozhraní Runnable, aby mohla být spuštěna jako samostatné vlákno.

\subsubsection{Rozdělení úlohy do vláken}
Aplikace má několik vláken z podstaty frameworku. Ta pro nás nejsou podstatná a
proto jim nebudeme věnovat další prostor. Části aplikace, které jsou pro nás
zásadní běží ve třech následujících vláknech.
\paragraph{UI vlákno} reaguje na požadavky uživatele a je zodpovědné za
vykreslování prvků uživatelského rozhraní. Z podstaty věci není vhodné umisťovat
do tohoto vlákna žádné déle trvající úlohy, protože uživatelské rozhraní potom
přestane po dobu práce této úlohy reagovat a to není z hlediska uživatelského
rozhraní žádaným stavem.

Proto v UI vlákně pracuje pouze rozcestník a průvodci. Jakmile uživatel nastaví
a spustí samotnou úlohu, je spuštěno separátní vlákno, které je monitorováno
pomocí rozhraní IRunnableWithProgress.

\paragraph{Výstupní vlákno} vytváří události na výstupním hardware. Jak již bylo
v předchozí sekci popsáno, toto vlákno periodicky vysílá signál na výstupní
zařízení. V případě varianty s odpovědí je potom použito i další vlákno, které
je při inicializaci tohoto vlákna spuštěno.

\paragraph{Vstupní vlákno} periodicky testuje stav vnějších zařízení a
zaznamenává jeho změny. Tato část aplikace musí operovat v separátním vlákně,
protože nemůže brzdit a způsobovat nepřesnosti výstupního vlákna.

\subsubsection{Přesnost měření}
Díky tomu, že žádaná přesnost aplikace je cca 5 milisekund na periodu, bylo
možné použít metodu java.lang.Thread.sleep(long) na spožďování vláken. Existuje
i metoda java.lang.Thread.sleep(long, int), která akceptuje i počet nanosekund
po které má být exekuce vlákna pozastavena. Tato metoda ale ve většině
implementací JVM stejně zaokrouhluje na jednotky milisekund a žádný běžný
operační systém není schopen tento požadavek dodržet. Již na zmiňované
bakalářské práci bylo ověřeno, že maximální rychlost čtení z paralelního portu je cca 300 KHz.
Vzhledem k tomu, že rychlost procesorů a celého toku aplikace je řádově větší,
je popisovaná varianta dostatečná a v praxi dosahuje chyby cca 1 ms na periodu.


\subsubsection{Přístup k nativním prvkům systému}
Přístup k nativním prvkům se volně inspiruje v několikrát zmiňované bakalář\-ské práci. Z hlediska aplikace a Javy byla vytvořena třída ParallelPortAccessor.
Tato má za úkol zapouzdřovat přístup k hardware a zjednodušovat ho. Je
koncipovaná podle návrhového vzoru singleton, ale není to ukázková implementace.
Třída je stavová a předpokládá se jenom jedna instance. 

Plugin ve kterém se tato třída nachází je pak rozšiřován dvojicí fragmentů.
Jeden pro systémy Win32 x86 a druhý pro Linux x86\_64. 

Nativní knihovna je potom načítána pomocí statického inicializátoru třídy.
Zajímavým faktem je, že proměnná LIBRARY\_NAME je stejná pro všechny systémy a
to ``parportaccessor''. Java sama na Windows implementacích hledá
``parportaccessor.dll'' a na Linuxu potom ``libparportaccessor.so''.


\begin{code}
static {
    LOG.info("Loading shared library \"" + LIBRARY_NAME + "\"");
    try {
    	System.loadLibrary(LIBRARY_NAME);
    } catch (UnsatisfiedLinkError e) {
    	LOG.log(Level.SEVERE, "Loading shared library \"" + LIBRARY_NAME + "\" failed.", e);
    }
}
\end{code}

Tyto knihovny jsou realizovány v jazyce C a volány pomocí rozhraní JNI. Volání
metody pomocí tohoto rozhraní vypadá následovně.

\begin{code}
	private static native int writeByte(int address, int value);
\end{code}

Tento kód je automaticky předelegován na nativní knihovnu díky klíčovému slovu
native. Kód takovéto metody v nativním prostředí Linux vypadá následovně.

\begin{code}
	JNIEXPORT jint JNICALL Java_net_zarubsys_parporttester_io_ParallelPortAccessor_writeByte
	    (JNIEnv * env, jclass this, jint address, jint value) {
		    outb(value, address);
		    return 0;
	}
\end{code}

V prostředí Windows potom takto.

\begin{code}
	JNIEXPORT jint JNICALL Java_net_zarubsys_parporttester_io_ParallelPortAccessor_writeByte 
	     (JNIEnv * env, jclass this, jint address, jint value) {
		    _outp(address, value);
		    return 0;
	}
\end{code}

Je tedy zřejmé, že jak Windows tak Linux problematiku nativního
nízkoúrovňového přístupu k systémovým zdrojům řeší velice podobně. 

Obě knihovny byly kompilovány přímo na odpovídajícím systému. Na Linuxu jsem
použil kompilátor GCC. Na Windows potom MS Visual Studio 9.0.
\newpage
\section{Výsledky testování zadavatelem}
Testování zákazníkem probíhalo na třech úrovních.

Jako první zákazník testoval kognitivním průchodem návrh uživatelským prostředím
navrženým pomocí Balsamiq Mockups. V tomto testu byly odhal\-ena některá zásadní
nedorozumění během zadání.

Po jejich odstranění bylo implementováno uživatelské rozhraní přímo do cílové
platformy. Výstup byl potom opět konzultován se zadavatelem. Zde již nebyly
shledány žádné nedostatky. Během tohoto testu byly upřesněny základní požadované
hodnoty masek a adres portů.

Poslední fází testování bylo spojení cílového hardware s aplikací. V tomto bodě
došlo k mírným komplikacím, které byly způsobeny tím, že HW nebyl dlouho
používán a jeho spolehlivost byla pochybná. Testováním na analyzátoru signálů
bylo prokázáno, že se aplikace chová podle přání zadavatele. Byly ověřeny také
nepřesnosti a latence a bylo shledáno, že oboje spadá do normy zadavatele a
dokonce ji i vysoce překračuje. Tento fakt byl překvapením, protože aplikace,
která využívá několika vláken pracovala časově velice přesně na starším
jednojádrovém procesoru P4.

\newpage
\section{Závěr}
Práce splnila očekávání a požadovaný software byl dodán zadavateli v
před\-pokl\-ádané kvalitě jak po technické stránce, tak i po stránce návhru
uživatel\-ského rozhraní.

Během práce se potvrdilo, že Java, ačkoliv není na první pohled vhodným
kandidátem na práci s nativními prvky HW, může tuto roli bez problémů plnit za
předpokladu implementace minimální části kódu v jazyce C nebo C++.

Platforma Eclipse se navzdory své rozměrnosti potvrdila jako velice silný
nástroj pro vývoj aplikací, které vyžadují těžkého klienta. Jedním ze
základn\-ích požadavků byla jednoduchost ovládání. Implementace v prostředí
Swing by s největší pravděpodobností neměla tento efekt, protože běžný uživatel očekává
stejné nástroje, jako ty, které má při běžné práci k dispozici.

Textová část práce byla vytvořena za pomocí balíku maker \LaTeX{}. Díky tomu
bylo dosaženo vysokého typografického standartu bez náročného zpracování.

Jako prostředí pro psaní textu jsme využili plugin
TeXlipse\footnote{\urlref{http://texlipse.sourceforge.net/}}.
Jedná se o~rozšíření IDE Eclipse. Tento plugin fungoval bezchybně a bez něj by práce byla podstatně
složitější.

Na práci jsme aplikovali základní principy dělby práce v teamu a vzdálené
spolupráce za pomoci Skype a platformy Google Code ve~spojení
s~\mbox{Subclipe}\footnote{SVN plugin pro Eclipse IDE}. Tyto postupy se již
v~praxi na jiných projektech stejně jako nyní velice osvědčily.

Z celého projektu jsme si odnesli především nové zkušenosti se platformou
Eclipse, s Eclipse IDE, se systémem \LaTeX{} a se vzdálenou spoluprací.

Celkově lze výsledky práce označit za velmi uspokojivé a přínosné.
\newpage
\begin{flushleft}
\begin{thebibliography}{99}
\small

\bibitem{bachelor_thesis} Lukáš Záruba. \newblock \emph{Universal signal
analyzer}. \newblock Czech Technical University in~Prague, Faculty of~Electrical
Engineering, Department of~Computer Science and Engineering, 2009.

 
   
\bibitem{java} Wikipedia. \newblock Java. \newblock
\urlref{http://en.wikipedia.org/wiki/Java\_language}.

\bibitem{jni} Sheng Liang. \newblock \emph{Java(TM) Native Interface:
Programmer’s Guide and Specification (Java Series)}. \newblock Prentice Hall
PTR, 1999.

\bibitem{eclipse_platform} Wikipedia. \newblock Eclipse (Software). \newblock
\urlref{http://en.wikipedia.org/wiki/Eclipse\_(software)}.

\bibitem{eclipse_based_projects} Wikipedia. \newblock List of eclipse-based
software. \newblock
\urlref{http://en.wikipedia.org/wiki/List\_of\_Eclipse-based\_software}.

\bibitem{osgi} Wikipedia. \newblock Open Services Gateway initiative (OSGi).
\newblock
\urlref{http://en.wikipedia.org/wiki/Osgi}.

\bibitem{equinox} Wikipedia. \newblock Equinox (OSGi). \newblock
\urlref{http://en.wikipedia.org/wiki/Equinox\_OSGi}.

\bibitem{eclipse_plugin} Eclipse Team. \newblock Eclipse Plugin architecture.
\newblock
\urlref{http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin\_architecture.html}.

\bibitem{eclipse_fragment} Wiki Eclipse. \newblock Eclipse Plugin Fragment.
\newblock
\urlref{http://wiki.eclipse.org/FAQ\_What\_is\_a\_plug-in\_fragment\%3F}.

\bibitem{eclipse_feature} Eclipse Team. \newblock Eclipse online help. \newblock
\urlref{http://help.eclipse.org/helios/}.

\bibitem{eclipse_rcp} Wiki Eclipse. \newblock Rich Client Platform (RCP).
\newblock
\urlref{http://wiki.eclipse.org/Rich\_Client\_Platform/FAQ}.

\bibitem{swt} Wikipedia. \newblock Standard Widget Toolkit (SWT).
\newblock
\urlref{http://en.wikipedia.org/wiki/Standard\_Widget\_Toolkit}.

\bibitem{java_2d} Wikipedia. \newblock Java 2D. \newblock
\urlref{http://en.wikipedia.org/wiki/Java\_2D}.

\bibitem{jface} Wiki Eclipse. \newblock JFace. \newblock
\urlref{http://wiki.eclipse.org/index.php/JFace}.

\bibitem{jdt} Eclipse Team. \newblock Java Development Tools (JDT). \newblock
\urlref{http://www.eclipse.org/jdt}.

\bibitem{pde} Eclipse Team. \newblock Plug-in Development Environment (PDE).
\newblock \urlref{http://www.eclipse.org/pde}.

\normalsize{}
\end{thebibliography}
\end{flushleft}

\newpage
\section*{Seznam použitých zkratek}
(Řazeno abecedně)\newline
\small
\begin{description}
\item[API] - Application Programming Interface
\item[CASE] - Computer Aided Software Engineering
\item[GC] - Garbage Collector
\item[GUI] - Graphical User Interface
\item[IDE] - Integrated Development Environment
\item[IEEE] - Institute of Electrical and Electronics Engineers (Institut pro
elektrotechnické a elektronické inženýrství)
\item[EZS] - Elektronický zabezpečovací systém
\item[HTML] - HyperText Markup Language
\item[JDT] - Java Development Tools
\item[JNI] - Java Native Interface
\item[JVM] - Java Virtual Machine
\item[\LaTeX{}] - balík maker typografického programu \TeX{}
\item[LPT] - Line Printer Terminal
\item[MVC] - Model View Controller
\item[OSGi] - Open Services Gateway initiative
\item[PDE] - Plug-in Development Environment
\item[RCP] - Rich Client Platform
\item[SDK] - Software Development Kit
\item[SWT] - Standard Widget Toolkit
\item[USB] - Universal Serial Bus
\item[VM] - Virtual Machine
\end{description}
\normalsize{}
\end{document}
